Virtualization permits multiplexing of an underlying host machine between different virtual machines. The host computer allocates a certain amount of its resources to each of the virtual machines. Each virtual machine is then able to use the allocated resources to execute applications, including operating systems (referred to as guest operating systems (OS)). The software layer providing the virtualization is commonly referred to as a hypervisor and is also known as a virtual machine monitor (VMM), a kernel-based hypervisor, or a host operating system. The hypervisor emulates the underlying hardware of the host computer, making the use of the virtual machine transparent to the guest operating system and the user of the computer.
Loading a host OS is normally performed by loading firmware, which scans “real” devices in a computing system in some predetermined order, until a bootable device is found and the host OS is loaded and booted from the bootable device. Conventional loading firmware attempts to enable all resources for (supported) devices in a computing system before the OS is loaded, even though only one such device may be used to load the OS, and others may be used by the OS after the OS is loaded. This may create device resource conflicts: for example, each device may need a certain amount of PIO memory, while the total amount of PIO memory in the computing is limited to less than 64 Kbytes.
Loading a guest OS in a virtual environment is normally performed by a hypervisor, which scans “virtual” devices in a computing system in some predetermined order, until a bootable virtual device is found and the virtual OS is loaded and booted from the “bootable” virtual device. Similar guest resource conflicts may arise among guests devices within a virtual machine or between virtual machines. For example, a 32 bit guest can address 4 GBytes of memory. As a result, virtual memory becomes a guest limited resource. Virtual IO ports and interrupt lines are another example.